<html>
<head><meta charset="utf-8"><title>Some random thoughts about infallible allocations · t-libs/wg-allocators · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/index.html">t-libs/wg-allocators</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html">Some random thoughts about infallible allocations</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="186376616"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186376616" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186376616">(Jan 23 2020 at 10:44)</a>:</h4>
<p><strong>True infallible allocators are not possible!</strong><br>
An allocator is used to... allocate. Each time an allocator allocates, a memory area is returned. So how can an allocator be infallible when memory is finite? </p>
<p><strong>So what does mean infallible in this context?</strong><br>
I can only think of one kind of allocator: You know the memory size from the beginning, either as a parameter in the constructor, or prescribed by the type itself. Then the allocator is basically nothing else but a low-level <code>Vec</code>. In such cases, the allocator could panic instead of aborting, since the user theoretically knows how much space is left in the allocator.</p>
<p><strong>How to implement infallibility?</strong><br>
In the current <code>AllocRef</code> trait, we always return <code>AllocErr</code> as error. To mark an allocator as infallible, we need an associated error type. If this is set to <code>!</code>, an allocator is infallible. There may be other possibilities, but I can't think of any right now.</p>
<p><strong>What do we want/need infallible allocators for?</strong><br>
Infallible allocators would return <code>Result&lt;_, !&gt;</code>. <br>
<code>Result&lt;_, !&gt;::unwrap()</code> is a noop while <code>Result&lt;_, AllocErr&gt;::unwrap()</code> requires a branch. This matters in tight loops, where those allocator could be used (e.g. in game development).</p>



<a name="186382453"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186382453" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186382453">(Jan 23 2020 at 12:17)</a>:</h4>
<p>I think this is a false premise. “Infallible” in the context of memory allocation does <em>not</em> mean that failure never happens. (This may be confusing and perhaps it was not a great choice of terminology, but at this point it is somewhat established.) It means that the possibility of failure is not part of the “main” code path. In a fallible API, failure is represented as part of the return value of relevant functions or methods, for example with <code>Result</code> or a nullable pointer. In a so-called infallible API means that a function diverges (panics, aborts, …) on failure.</p>



<a name="186382476"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186382476" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186382476">(Jan 23 2020 at 12:17)</a>:</h4>
<p><code>Vec::try_reserve</code> is fallible, <code>Vec::reserve</code> is infallible</p>



<a name="186382563"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186382563" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186382563">(Jan 23 2020 at 12:18)</a>:</h4>
<p>Thanks for clarifying this!!</p>



<a name="186382722"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186382722" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186382722">(Jan 23 2020 at 12:20)</a>:</h4>
<p>My personal opinion is that <code>Result&lt;_, !&gt;</code> is not a good way of designing infallible APIs. The point of infallibility is that you deal with failure early so that downstream callers have the convenience of not worrying about it. <code>Result&lt;T, !&gt;</code> is less convenient than a plain <code>T</code>.</p>



<a name="186382843"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186382843" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186382843">(Jan 23 2020 at 12:22)</a>:</h4>
<p>I always have associated <code>infallible</code> with "no error". This is a game changer :)</p>



<a name="186382868"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186382868" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186382868">(Jan 23 2020 at 12:22)</a>:</h4>
<p>Well yeah, <code>Vec::reserve</code> has no error (visible in its signature)</p>



<a name="186383013"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383013" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383013">(Jan 23 2020 at 12:24)</a>:</h4>
<p>Yes, but I meant no errors at all, so the allocator cannot error either</p>



<a name="186383051"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383051" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383051">(Jan 23 2020 at 12:25)</a>:</h4>
<blockquote>
<p><code>Vec::try_reserve</code> is fallible, <code>Vec::reserve</code> is infallible</p>
</blockquote>
<p>This is the game changer for me ;)</p>



<a name="186383145"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383145" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383145">(Jan 23 2020 at 12:26)</a>:</h4>
<blockquote>
<p>Yes, but I meant no errors at all, so the allocator cannot error either</p>
</blockquote>
<p>Like you said, that doesn’t exist</p>



<a name="186383147"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383147" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383147">(Jan 23 2020 at 12:26)</a>:</h4>
<p>As everyone (in this wg) knows, that <code>reserve</code> may abort on allocation failure.</p>



<a name="186383222"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383222" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383222">(Jan 23 2020 at 12:27)</a>:</h4>
<p>So <code>type Error = !</code> could never exist in <code>AllocRef</code></p>



<a name="186383314"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383314" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383314">(Jan 23 2020 at 12:28)</a>:</h4>
<p><a href="https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#tymethod.alloc" target="_blank" title="https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#tymethod.alloc">https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#tymethod.alloc</a> is fallible through returning a nullable pointer. I think it would be very reasonable to add a convenience infallible API like <code>fn(alloc: &amp;impl GlobalAlloc, layout: Layout) -&gt; NonNull&lt;u8&gt; { NonNull::new(alloc.alloc(layout)).unwrap_or_else(|| std::alloc::handle_alloc_error(layout)) }</code></p>



<a name="186383318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383318">(Jan 23 2020 at 12:28)</a>:</h4>
<p>And similar for other methods</p>



<a name="186383330"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383330" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383330">(Jan 23 2020 at 12:28)</a>:</h4>
<p>Or maybe a generic wrapper struct that provides infallible methods</p>



<a name="186383509"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383509" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383509">(Jan 23 2020 at 12:31)</a>:</h4>
<p>The problem here is the naming of the function. The term <code>try</code> is already established in the Rust community, but <code>try_alloc</code> matches the fallible one, which we cannot change, as <code>GlobalAlloc</code> is stabilized</p>



<a name="186383559"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383559" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383559">(Jan 23 2020 at 12:31)</a>:</h4>
<p>Thinks like <code>alloc_infallible</code> sounds weird IMO</p>



<a name="186383603"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383603" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383603">(Jan 23 2020 at 12:32)</a>:</h4>
<p>A <code>Result</code> with an associated error type is no the only option, and I feel it’s not a very good one. Encoding fallibility in the type system has a convenience cost (you need that <code>unwrap</code> or <a href="https://github.com/rust-lang/rust/issues/61695" target="_blank" title="https://github.com/rust-lang/rust/issues/61695"><code>into_ok</code></a> call)</p>



<a name="186383688"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383688" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383688">(Jan 23 2020 at 12:34)</a>:</h4>
<blockquote>
<p><code>Result&lt;_, !&gt;::unwrap()</code> is a noop while <code>Result&lt;_, AllocErr&gt;::unwrap()</code> requires a branch. This matters in tight loops, where those allocator could be used (e.g. in game development).</p>
</blockquote>
<p>I’d also dispute that claim without profiling a real-world program. My guess would be that the cost of that branch is often insignificant compared to everything else for example a game does</p>



<a name="186383760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383760">(Jan 23 2020 at 12:34)</a>:</h4>
<p>An associated error type could only bubble more error infos to the user, but that wouldn't change the way the errors have to be handled, so I think those issues are not related</p>



<a name="186383884"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383884" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Simon Sapin <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383884">(Jan 23 2020 at 12:36)</a>:</h4>
<p>For the global allocator (as opposed to adding an allocator type parameter to container types), naming is the least of your worries. <code>std::alloc::Global</code> is “connected” to <code>#[global_allocator]</code> at link-time, so you can’t have an associated type or generics or anything type-level</p>



<a name="186383903"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383903" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383903">(Jan 23 2020 at 12:36)</a>:</h4>
<blockquote>
<p>I’d also dispute that claim without profiling a real-world program [...]</p>
</blockquote>
<p>Well, that isn't a thing anyway then, as I know the terminology of "infallible" and "fallible" in the context of allocations now.</p>



<a name="186383941"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186383941" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186383941">(Jan 23 2020 at 12:37)</a>:</h4>
<p>As literal infallible allocations does not exist. </p>
<p>An allocator implementation should not decide, on how it's errors are handled.</p>



<a name="186479975"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186479975" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186479975">(Jan 24 2020 at 10:44)</a>:</h4>
<p>The way I see infallibility in allocators is: "if it returns, it allocated"</p>



<a name="186479982"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186479982" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mike Hommey <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186479982">(Jan 24 2020 at 10:44)</a>:</h4>
<p>as in "if it returns at all"</p>



<a name="186502365"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186502365" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186502365">(Jan 24 2020 at 15:35)</a>:</h4>
<p>"mandatory" vs "discressionary" might be better</p>



<a name="186502467"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186502467" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> John Ericson <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186502467">(Jan 24 2020 at 15:36)</a>:</h4>
<p>Regardless of the name I do agree with the changes that's been discussed, and yes they do use <code>Result</code>.</p>



<a name="186548779"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186548779" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186548779">(Jan 25 2020 at 00:39)</a>:</h4>
<p><del>We rename <code>Alloc</code> to <code>AllocRef</code> because types that implement <code>Alloc</code> are a reference, smart pointer, or ZSTs. This question is another reason, why this rename is a good idea</del></p>



<a name="186548859"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186548859" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186548859">(Jan 25 2020 at 00:41)</a>:</h4>
<p><del>It is not possible to have an allocator like <code>MyAlloc([u8; N])</code>, that owns the memory and also implements <code>Alloc</code>. That would mean, that moving a <code>Vec&lt;T, MyAlloc&gt;</code> would need to correct the internal pointer, which is not possible. You have to encapsule the lifetime yourself by <code>impl AllocRef for &amp;(mut) MyAllocator</code></del></p>



<a name="186548870"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/Some%20random%20thoughts%20about%20infallible%20allocations/near/186548870" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/Some.20random.20thoughts.20about.20infallible.20allocations.html#186548870">(Jan 25 2020 at 00:41)</a>:</h4>
<p>Wrong topic...</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>